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Abstract 

Interface adapters allow applications written for one interface to be 
reused with another interface without having to rewrite application code, 
and chaining interface adapters can significantly reduce the development 
effort required to create the adapters. However, interface adapters will 
often be unable to convert interfaces perfectly, so there must be a way 
to analyze the loss from interface adapter chains in order to improve 
the quality of interface adaptation. This paper describes a probabilis- 
tic approach to analyzing loss in interface adapter chains, which not only 
models whether a method can be adapted but also how well methods can 
be adapted. We also show that probabilistic optimal adapter chaining is 
an NP-complete problem, so we describe a greedy algorithm which can 
construct an optimal interface adapter chain with exponential time in the 
worst case. 

1 Introduction 

Network services are being developed all the time, along with the interfaces 
that specify how these services should be accessed. Only a very small number 
of the interfaces to these services are standardized, and many interfaces can be 
developed for different services which have very similar functionality. In order 
to access a different interface than a client was written for without rewriting the 
client, interface adapters could be used to convert invocations in one interface to 
another, which can also be chained to reduce the number of interface adapters 
that must be created [5| [TB I [71 [Ti l [TT ] . 

However, it is unlikely that interface adaptation can be done perfectly, since 
interfaces are usually developed independently of each other with no regard for 
compatibility. Adaptation loss will usually result as certain methods cannot be 
adapted by the interface adapter, and the problem is only worse when adapters 
are chained. Even analyzing how much loss results from an interface adapter 
chain is not a trivial problem that can be modeled as a shortest path problem. 

Our previous work [2] took the approach of assuming that a method in 
a target interface could be implemented as long as all the prerequisite methods 
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in the source interface were available. However, a discrete approach such as 
this ignores the possibility of partial adaptation of methods, where an adapted 
method may not be able to be invoked with all possible arguments because of 
limitations with methods in a source interface. For a trivial example, nega- 
tive numbers for a square root function cannot be handled if either the source 
interface or target interface are unaware of imaginary numbers. 

We describe a probabilistic approach to handling the partial adaptation of 
methods, where the loss may occur not just due to missing functionality or meth- 
ods, but also due to an interface adapter being unable to handle all arguments 
given for a method in a target interface. We first investigate how probabili- 
ties should be expressed, where independence assumptions are made so that we 
can obtain a computational model that can be feasibly used in a real system. 
Based on this probabilistic model, we define how to express probabilistic loss 
in interface adaptation and how to model interface adapters, which can then 
be used to probabilistically analyze loss in interface adapter chains. As in the 
discrete approach [2 , probabilistic optimal adapter chaining is NP-complete, so 
we describe a greedy algorithm which can construct an optimal adapter chain 
with exponential run-time in the worst case. 

This paper is structured as follows. In section [31 we describe elements from 
the discrete approach which we use in developing the probabilistic approach. In 
section m we formulate the probabilistic approach for analyzing loss in interface 
adapter chains. Section [S] shows that probabilistic optimal adapter chaining 
is NP-complete, and section [6] describes an algorithm which can construct an 
optimal adapter chain with exponential run-time in the worst case. We discuss 
related work in section [21 and section [71 concludes. 

2 Related work 

Ponnekanti and Fox [15] suggests using interface adapter chaining for network 
services to handle the different interfaces available for similar types of services. 
They provide a way to query all services whose interfaces can be adapted to a 
known interface. They also support lossy adapters, but the support is limited to 
detecting whether a particular method and specific parameters can be handled 
at runtime. They do not provide a way to analyze the loss of an interface adapter 
chain, so they are unable to choose a chain with less loss when alternatives are 
available. 

Gschwind jj] allows components to be accessed through a foreign interface 
and implements an interface adaptation system for Enterprise JavaBeans [13] . 
It implements a centralized adapter repository that stores adapters, along with 
weights that mark the priority of an adapter. Dijkstra's algorithm [5] is used 
to construct the shortest interface adapter chain that adapts a source interface 
into a target interface. While there is support for marking an adapter as lossy 
or not, it does not have the capability to properly analyze and compare the loss 
in interface adapter chains. 

Vayssiere |16| supports the interface adaptation of proxy objects for Jini [1]. 
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The goal is to enable clients to use services even when they have different in- 
terfaces than expected. It provides an adapter service which hooks into the 
lookup service, so that a client can use a proxy object without having to be 
aware that any adaptation occurs. No consideration is spent on the possibility 
that interface adapters may not be perfect. 

There is also other work using chained interface adapters which focus on 
maintaining backward compatibility as interfaces evolve [101 |8l [9] . Since these 
are applied to different versions of the same interface, they do not consider the 
possibility of adaptation loss, in contrast to other work where the focus is on 
adaptation between different interfaces with potentially irreconcilable incom- 
patibilities. 

3 Preliminaries 

In this section, we describe the bare essentials from a discrete approach of 
analyzing lossy interface adapter chaining [2] , which are necessary for the prob- 
abilistic approach developed in section |4l In this section as well as in the rest of 
the paper, a range convention for the index notation used to express matrixes 
and vectors will also be in effect [4]. 

We take the view that an interface is a specification of a collection of methods 
(which can also be called operations, methods, member functions, etc.) which 
specify the concrete syntax and types for invoking actions on a service (which 
can also be called an object, module, component, etc.) that conforms to the 
interface. 

An interface adapter transforms calls for one interface into calls for another. 
For example, if one interface has a method setAudioProperties while another 
interface has methods setVolume and setBalance, an interface adapter could 
handle a call to setAudioProperty with the former interface using calls to set- 
Volume and setBalance when the actual service conforms to the latter interface. 

Adapting interfaces using a chain of interface adapters means converting 
calls to an interface to another using one interface adapter, then converting 
them again to yet another interface with a subsequent interface adapter, and so 
on until we can convert calls for a desired source interface to calls for a desired 
target interface. 

A method dependency matrix is used to express the methods in a source 
interface necessary for providing methods in a target interface: 

Definition 1. A method dependency matrix aji is a boolean matrix where: 

• ail is true, while an is set to false for all i ^ 1. 

• // method j can always be implemented in the target interface, set aji to 
false for all i. 

• If method j can never be implemented given the source interface, set Oji 
to true, while aji is set to false for alii ^ 1. 
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• // method j depends on the availability of actual methods in the source 
interface, then aji is false, while aji is true if and only if method j in the 
target interface can be implemented only if method i in the source interface 
is available. 

Method dependency matrixes can be composed, which in effect models two 
interface adapters chained together as a single equivalent adapter in terms of 
loss: 

Definition 2. Given method dependency matrixes bkj andoji, the composition 
operator ® of two method dependency matrixes is defined as: 



Theorem 1. The composition operator for method dependency matrixes is as- 



We can also define an interface adapter graph, which is a directed graph 
where interfaces are nodes and adapters are edges. If there are interfaces Ii and 
I2 with an adapter A that adapts source interface Ii to target interface I2 , then 
Ii and I2 would be nodes in the interface adapter graph while A would be a 
directed edge from Ii to 12- 

Definition 3. An interface adapter graph is a directed graph where interfaces 
are nodes and adapters are edges. The source node for an edge corresponds to 
the source interface, while the target node for an edge corresponds to the target 
interface. 

4 Probabilistic analysis 

When an interface adapter translates a call to a method in the target interface 
to calls to a method in the source interface, it is possible that the translation 
cannot be done perfectly. If the source interface lacks certain capabilities, then 
the adapter may not be able to properly process specific parameters received by 
a method. 

For example, there may be multiple video playback interfaces with adapters 
between them as in figure [1] where each interface is only able to handle a 
specific set of video formats. For instance, if client code is written to access 
interface Video2 but the actual service has interface Videol, then parameters 
to the playback method for Video2 with formats MOV and RMV cannot be handled 
properlylj In another situation where client code is written for Video3 but the 
actual service conforms to Videol, we would need an interface adapter chain 
from Videol to VideoS, and we would like to know if the chain that goes through 
Video2 or the one that goes through Video4 is better. 

^We ignore the possibility that video conversion could be done by the adapter itself. 
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Figure 1: Adapting playback methods in video playback interfaces which sup- 
port different video formats. 



With the discrete approach, which only looks at whether methods are avail- 
able or not, we must make a choice about what to do with methods that can 
be only partially adapted. Conservatively treating such methods as being un- 
available excludes the use of interface adapter chains that can do an imperfect 
but mostly complete job of adapting such methods. On the other hand, opti- 
mistically treating such methods as being available could result in the selection 
of an interface adapter chain that is much worse than other chains in terms 
of how complete the adaptation is. In figure [TJ VideoS could not be adapted 
from Videol at all with the conservative treatment, while with the optimistic 
treatment we would not be able to determine that the chain which goes through 
Video4, which can support AVI, OGM, MKV, MPG, and ASF, is superior than the 
one that goes through Video2, which can only support OGM, MKV, and MPG. 

The probabilistic approach we introduce here takes into account that meth- 
ods can be partially adapted, relaxing the binary limitation of only treating a 
method as available or not. 

4.1 Probabilistically modeling interface adaptation 

We develop a probabilistic approach by starting off with the most general form of 
expressing the probabilities and adding assumptions until we have a probabilistic 
formula that is practical. Without additional assumptions, the probabilities 
can only be expressed in a way that is useless for analyzing real systems. The 
additional assumptions allow us to express the desired probabilities in a way 
that they can be feasibly computed from a set of values that can be measured 
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Method m of interface I can properly handle argument a. 

Method m of interface / can properly handle its argument. 

Interface adapter A can successfully convert an argument 
for method m in the target interface to an argument for 
method m! in the source interface and convert back the 
result. 

Table 1: Probabilistic events. 



We first describe the notation for expressing certain probabilistic events in 
table[TJ These events denote whether a method can handle a given argument, or 
whether an interface adapter can convert an argument for a method in a target 
interface to an argument for a method in the source interface and successfully 
convert back the result. We assume that a method only accepts a single argu- 
ment: this is not a problem since methods with multiple arguments can simply 
be modeled as a method accepting a single tuple with multiple components. If a 
method does not need an argument, we treat it as receiving a dummy argument 
anyway. 

Let us say that we wish to adapt methods in source interface Is into method j 
in target interface It- The most general form for expressing the probability that 
a method could handle an argument is to sum the probabilities for every possible 
argument, where we must consider the probability of the method receiving a 
specific argument and then the probability that the method can handle it: 

nVjjr) = E P{V,jAa))P{A = a) (2) 

a 

The most general form for expressing the probability requires that we know 
the probability distribution of arguments, which is not feasible except for the 
simplest of argument domains. For example, the probability distribution for a 
simple integer argument may require 2^^ or 2®^ probabilities to be expressed 
for the typical computer architecture, and even measuring such a probability 
distribution may not be feasible in the first place. It is also not feasible that 
we already know the probabilities for how a method can handle each and every 
possible argument. 

For this reason, we make the assumption that the probabilities do not de- 
pend on the specific arguments. Given this assumption, we can now express 
P(Vj jj,) in terms of whether an argument can be converted and whether it can 
be handled. More specifically, this means that for all methods in the source 
interface that the interface adapter A requires to implement a method in the 

^ There is a more precise approacli using abstract interpretation tliat does not rely on 
such assumptions, but it is much more difBcult to set up and requires exponential space 
complexity j^]- 



Vm,l{a) 

iTi — ' 



in practice 
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target interface, it must be the case that the argument can be converted and 
the method in the source interface can handle the converted argument. Using 
the method dependency matrix aji for adapter A, PiVjj,^) can be expressed as: 

P{v,,i^ i^^^^s n c/_,) j (3) 

This is stiU too unwieldy an expression to be practical, since it is unclear how 
dependencies in the events for different methods in the source interface affect the 
overall probability. It would also be unclear how to measure the probabilities 
beforehand without trying out every possible argument and configuration of 
interface adapter chains, something that is clearly not feasible. Therefore we 
make an additional assumption that the events for separate methods in the 
source interface are independent. 

With the additional assumption, P{Vjjj.) can be expressed as: 

P(.Vjj^)^l[PiVusnCf_,,) (4) 

However, equation ^ is still not appropriate for practical use. The reason 
is that it entangles the work done by the interface adapter and whether the 
method in the source interface can handle the converted argument. Basically, 
the probabilities intrinsic to the interface adapter and the source interface are 
entangled. If the source interface itself is the result of adaptation through an 
interface adapter chain, then we have the problem of a configuration-dependent 
event being entangled with a configuration-independent event, and there is no 
simple way to derive the required probabilities. 

Thus we make one final additional assumption that the probability an inter- 
face adapter can successfully convert arguments and results is independent from 
the probability that a method in the source interface can handle an argument. 
This allows us to express P{Vjjj.) as: 

PiV,j^)=l[P(^^'is)P{Cf^.) (5) 

aji 

Equation ([5]) is finally in a form that can be used practically. The probability 
that an interface adapter A can successfully convert an argument for method j 
in the target interface to an argument for method i in the source interface, 
P{Cj^_^^), is a value that is intrinsic to an interface adapter. In principle, it 
could be measured empirically by exhaustively testing the interface adapter 
to see which arguments it can accept, although in practice more sophisticated 
testing based on random samples would be used. It might even be possible to 
obtain the probabilities through analysis of the interface adapter code. The 
probability that method rrii in source interface Is can handle an argument, 
PiVijs)^ is also a value that can be obtained, either through analytical or 
empirical means similar to measuring probabilities from interface adapters if 
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Is is an interface to an actual service, or through a recursive application of 
equation ([5]) when Ig is an adapted interface. 

4.2 Formalizing adapter loss 

We now have the basis for describing a framework similar to the one devel- 
oped for the discrete chain approach. We define a method availability vector 
and a method dependency matrix, but in addition we also define a conversion 
probability matrix. 

As before, the method availability vector pi expresses how well a method 
is supported in an interface, and it is not intrinsic to an interface but rather 
represents the loss from interface adaptation. The components for a method 
availability vector in the probabilistic approach are probabilities, pi is defined 
as the probability that method i can handle an argument it receives, i.e. pi = 
PiVij). 

The method dependency matrix is the same as defined in section|3]and is used 
in equation ([5|). Unlike for the discrete chain approach, however, the method 
dependency matrix does not suffice to describe the relevant information for an 
interface adapter. We also require a set of probabilities P(Cj^j) for how well an 
interface adapter converts an argument for a method in the target interface to 
that for the relevant method in the source interface. The conversion probability 
matrix tji is defined in terms of these probabilities, where tji = P(Cjl^j). 

Given method availability vector p^, method dependency matrix Oji, and 
conversion probability matrix tji, we can now define the adaptation operator 0. 
Instead of just the method dependency matrix being applied to the method 
availability vector, the conversion probability matrix must also be applied in 
conjunction with the method dependency matrix: 

Definition 4. Given method dependency matrix a,ji, conversion probability ma- 
trix tji, and method availability vector pi, the probabilistic adaptation operator 
® is defined as: 

iaji,tjt) ^Pt = Y]_ t]i Pi (6) 

aji 

Definition 5. A tuple {oji, tji) of a method dependency matrix and a conversion 
probability matrix is called a probabilistic adaptation factor. The probabilistic 
adaptation factor for an interface adapter A is denoted as depend (A). 

It should be emphasized that equation (j6|) is only rigorously correct given 
the following three assumptions. However, the three assumptions make it pos- 
sible to feasibly compute P{Vij) from values that can be feasibly measured or 
estimated a priori in a rigorously sound manner, instead of having to define 
an ad hoc computational framework where definitions are vague in their opera- 
tional meaning. While it is not hard to see that the assumptions would not hold 
for most real systems, it is an open question how closely the probabilistic ap- 
proach based on these assumptions approximates actual losses due to interface 
adaptation. 
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• The probabilities do not depend on the specific arguments. 

• The events for separate methods in the source interface are independent. 

• The probabihty that an interface adapter can successfully convert argu- 
ments and results is independent from the probability that a method in 
the source interface can handle an argument. 

It should be noted that equation (|6]) is incomplete in that it is ambiguous 
what the result should be when no Uji is true. If this is the case, it could be 
that the method in the target interface can always be implemented regardless 
of availability of methods in the source interface, or it could be that the method 
cannot be implemented no matter what. 

The workaround is simple: a dummy method is defined for each interface, 
where the method dependency matrixes follow the same rules. For the conver- 
sion probability matrix, setting tji to zero for all j would yield the expected re- 
sults, given the usual convention that an empty product has a value of one |12)FI 
We will denote a method availability vector for interface / in which all methods 
are available and can handle all arguments by I'j, where all components have 
value one except for the component corresponding to the dummy method, which 
has value zero. 

4.3 Adapter composition 

We would like to be able to derive a composite probabilistic adaptation factor 
from the composition of two probabilistic adaptation factors, which would be 
equivalent to describing the chaining of two interface adapters as if they were a 
single interface adapter. 

Given interfaces /i, I2, and I3, let the corresponding method availability 
vectors be pi , qj , and rk ■ In addition, let there be interface adapters Ai and A2 , 
where Ai converts Ii to I2 and A2 converts I2 to I3, with corresponding prob- 
abilistic adaptation factors {aji,tji) and {bkj,Ukj), respectively. We would like 
to know how to derive the probabilistic adaptation factor {cki,Vki) that would 
correspond to an interface adapter equivalent to Ai and A2 chained together. 

Cki is obviously derived in the same way as specified by the composition 
operator in section |3l As for Vki, from equation ([5]) and our assumptions: 



•^The values for tu do not matter except for i = 1, so they can be arbitrarily set to zero. 
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n '^kjtjiPi (7) 

We want the above to be equivalent to the fohowing: 

^■fc = Vki Pi 

= Y]^ Vki Pi (8) 

The composition operator is derived by carefully considering the terms in 
equations ([7]) and dS]), based on collecting the terms for fixed i. 

If we collect the terms in equation (O with fixed i, we have ([9]). It should be 
emphasized that ([9]) is not identical to ([7]): the former is a product over varying 
j with both i and k fixed, while the latter is a product over varying i and j with 
only k fixed. Also note that if bkj A Oji are all false for varying j, then no terms 
affect the result of ([7]). This would be equivalent to ^ having a value of one, 
which is expected from an empty product. 

Y[ Ukj tji Pi (9) 

On the other hand, consider the term in equation ([8]) with fixed i. If Vj {bkj A 
Qji) is false, i.e. bkj A aji are all false for varying j, then the term is excluded 
from the product and is equivalent to multiplying by one, instead. If it is true, 
on the other hand, then VkiPi is the term that corresponds to the fixed i. So if 
we set Vki Pi according to (fTO|) then equations ([8|) and (O end up having the 
exact same values. 

Vki = Y\. "'^j 

From this, we can conclude that the composition operator ® for two proba- 
bilistic adaptation factors should be defined as in definition [S] 

Definition 6. Given probabilistic adaptation factors (bkj,Ukj) and {aji,tji), the 
probabilistic composition operator ® is defined as: 

[bkj.Ukj) ® {a■j^,tj^) = (bkj ® Okj, W Ukjtji) (11) 

The ® operator is "associative" when applied to a probabilistic adaptation 
factors and a method availability vector 

^Remember that only A; is fixed in (0 and Jsjl, but both k and i are fixed in IjlOII . 
^It is technically not associative in this context since the Cg) operator in {bf^j ,Ukj)(X) {a^i ,tji) 
is not the same as the ® operator in (ciji^tji) ®pi. 



10 



Theorem 2. Applying the adaptation operator twice to a method availabiliy 
vector is the same as applying the composition operator and then applying the 
adaptation operator: 

{bkj,Ukj) ^ {{aji,tji) ®Pi) = {{bkjjUkj) ® {aji,tji)) ®pi 

Proof. 

{bkj,Ukj) ^ {{aji,tji) ^Pi) = (6fej,Ufej) <8> JJtjiPi 

aji 

= JJukjYltj^Pi 

bkj o-ji 

— Wfej tji Pi 

bkjAaji 

= n n '^kjtj^p^ 

VjibkjAuji) bkjAaji 

n I n 1 Pi 

bkj^aji \bkjAaji j 

= ibkj(E>aji, Y\_ Ukjtji)^pi 

bkj Aaji 

= {{bkj,Ukj)®{aji,tji))®Pi 



□ 



Likewise, probabilistic adaptation factor composition is associative: 



Theorem 3. The composition operator for probabilistic adaptation factors is 
associative: 

{cik,vik) O {{bkj,Ukj) O {aji, tji)) = {{cik,vik) <8) {bkj,Ukj)) <8) {aji, tji) 

Proof. Using the fact that bkj (8) ajt = \l j{bkj A aji) must be true if bkj A aji is 
true, we have: 

{cik,vik) (8> {{bkj,Ukj) <8) {aji, tji)) 
= {cik,vik)®{bkj®akj, W Ukjtji) 

bkjAaji 

= {Clk®bkj ® akj, Vlk Y\. '^kjtji) 

cikA(bkj^akj) bkjAaji 

= {cik^bkj ® akj, Vlk Ukjtji) 

cikAbkjAajiA(bkj^akj) 
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= {cik <8) bkj ® ttkj , "'^J 

(cik®bkj)/\aji \cikf\bkj j 

= {Clk "S) bkj, Y\. "^'fc "fej) ® («J»'*ji) 
cifcAbfcj 

= {{cik,vik) (Xi {bkj,Ukj)) (8) {aji,tji) 

□ 

However, probabilistic adaptation factor composition is not commutative, 
as can be easily seen by considering the composition of probabilistic adaptation 
factors whose components are not square matrixes. 

We can also show a monotonicity property, which formalizes the notion that 
extending an interface adapter chain results in worse adaptation loss: 

Theorem 4. // Ai and A2 are interface adapters, where Ai converts Ii to 
I2 and A2 converts I2 to I3, with {aji,tji) — depend{Ai) and {bkj,Ukj) = 
depend{A2) where they follow the rules for the dummy method in sections\^ 
let pk = {bkj,Ukj) ® I'j^ and p'^ = {bkj,Ukj) ® (a^i, tji) (g) I'j^ . Then 

P'k <Pk 

Proof. From our assumptions, we have: 

Pi^p'i^O 



Pk= W Ukj (12) 

i#iAf)fcj 



p'k = n = n n ^^^^ = n i ^'^^ n (^^^ 

i^lAbkjAaji bkj i^l/\aji bkj \ i^lAaji j 

If method k can never be implemented given the source interface, then bk\ 
will be true, and given that Uk\ will be zero, p'^, will also have to be zero. Other- 
wise, hk\ will be false, so we can do a term by term comparison of equations (|12p 
and (I13p , taking advantage of the fact that Ukj and tji are probabilities so that 
they are greater than or equal to zero and lesser than or equal to one: 

< [| tj^ < 1 
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Figure 2: Adapting playback methods in video playback interfaces which sup- 
port different video formats, expanded version of figure [H 



■ ■■ P'k < Pk (14) 

□ 

The definitions of the method dependency matrix and the method availabil- 
ity vector in section HTTl along with the associativity rules proven in this section, 
provide a succinct way to mathematically express and analyze the chaining of 
lossy interface adapters using a probabilistic approach. 

4.4 An example 

As an example, we apply the probabilistic approach to analyzing lossy inter- 
face chaining to the interface adapter graph of figure [21 which is a slightly ex- 
panded version of figure [T] Instead of simply four interfaces each having a single 
playback method, one of the interfaces, Video4, consists of two methods: the 
selectvideo method chooses a video file that should be played back, and the 
startPlayback method actually begins video playback. As with the example 
in figure [TJ each interface can handle different video formats. 

In this hypothetical scenario, there is an application written for interface 
VideoS which needs to use a video service that actually conforms to Videol. 
An interface adapter chain from Videol to VideoS would be required if the 
application is to use the video service. Since there are two possible interface 
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adapter chains, one which goes through Video2 and another which goes through 
Video4, we would want to use the chain that can support more video formats. 

The interface adapter from Videol to Video2 will be denoted Ai, the one 
from Video2 to VideoS will be denoted A2 , the one from Videol to Video4 will 
be denoted A3, and the one from Video4 to VideoS will be denoted A4. The 
method dependency matrix and conversion probability matrix for adapter A^ 
will be denoted ajj and t^^^, respectively. For each interface adapter, we assume 
that all methods in the target interface can be implemented in terms of all 
the methods in the source interface. For simplicity, we will not define dummy 
methods for any of the interfaces. 

Since the single method play of Video2 depends only on the single method 
playFile of Videol for Ai, aj^ only has a single true component. The same is 
true for aj^. On the other hand, the selectVideo and startPlayback methods 
of Video4 both depend on the single method playFile of Videol for A3, so a|j 
has two rows corresponding to the methods in the target interface, each with 
a single true component corresponding to the method in the source interface. 
The playVideo method of VideoS depends on both methods of Video4, so 
has a single row with two true components. The method dependency matrixes 
for each interface adapter are shown below: 



As for the conversion probability matrixes, a way to estimate the necessary 
probabilities is to compare the number of video formats each interface supportsO 
For Ai, among the formats MOV, OGM, MKV, MPG, RMV, and MP4 that Video2 should 
be able to support, the adapted interface can only support DGM, MKV, MPG, MP4 
since these are supported by the source interface Videol, so the conversion 
probability can be estimated as |. Assuming that startPlayback in Video4 
has no arguments to be converted, the conversion probability matrixes can be 
set as in the following: 



We will first look at the interface adapter chain that starts from Videol, 
passes through Video2, and ends at VideoS. Given a service conforming to 
Videol that is fully functional, i.e. supports all arguments it could receive, the 
sole component of the method availability vector corresponding to Videol is a 
probability of one. To see how the interface adapter chain formed from Ai and 
A2 adapts Videol to VideoS, i.e. the result of applying Ai to Videol and then 
applying A2, we can use the adaptation operator: 



^While this will not be accurate, it would be a relatively easy way to obtain a rough 
estimate that could be used for comparing the quality of different interface adapter chains. 
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We can also do the same thing for the interface adapter chain that starts from 
Videol, passes through Video4, and ends at Video3, i.e. the interface adapter 
chain formed from and A^: 

{a%,t%)®ialvt%)®{ 1 ) = ( 1 ) 

These results roughly estimate that when providing VideoS by adapting 
Videol, the chain formed from Ai and A2 would allow the interface to handle 
about I of the video files it is asked to play back, while the chain formed from 
A3 and A4 would allow the interface to handle about | of the video files it is 
asked to play back. This is consistent with how the former chain is worse in 
terms of only being able to handle DGM, MKV, and MPG, while the latter chain can 
handle significantly more formats, specifically AVI, DGM, MKV, MPG, and ASF0 In 
contrast, the discrete approach would tell us that the two chains are exactly the 
same. 

By using probability estimates of how well each interface adapter can adapt 
a source interface to a target interface, the probabilistic analysis scheme for 
interface adapter chaining outlined in this paper can be used to compare the 
quality of an interface adapter chains where methods may not be adapted per- 
fectly, in contrast to the discrete approach where methods are assumed to be 
adapted perfectly if they can be adapted at all. 

5 Probabilistic optimal adapter chaining 

Like the optimal adapter chaining problem with the discrete chain approach, 
the optimal adapter chaining problem with the probabilistic approach is NP- 
complete as well. This is intuitively the case since the probabilistic approach 
should be able to encompass the discrete approach, and we show this formally 
in this section. 

We first formally define the optimal adapter chaining problem in the prob- 
abilistic approach, which we will call PROB-CHAIN. Let us have an interface 
adapter graph {{Ii},{Ai}), where {/,} is the set of interfaces and {Ai} is the 
set of interface adapters. Let f'' be the probabilistic adaptation factor associ- 
ated with adapter Ak- Let S G {li} be the source interface and T G {/,} be 
the target interface. Let {rm} be the relative invocation probabilities for the 
methods in the target interface such that X)m ^ ^- Then the problem is 
whether there is an interface adapter chain [Ap^^) , ^p(2) j • ■ • : ^p(n)] such that 
the source of ^p(i) is S, the target of Apf^-f is T, and J2m "^m is at least as 
large as some probability X, where — (g) • • • (g) f^^^^^ ® f^^''''^ I5. 

Informally, this is an optimization problem which tries to maximize the 
probability that an argument can be handled by a method in a fixed target 
interface, obtained by applying an interface adapter chain on a fully- functional 
service which conforms to the source interface, {rm} would express how often 
methods are invoked relative to each other. 

^While the example here is simple enough that we can easily figure out exactly what types 
of arguments can be handled, it can be prohibitively difficult to do so in the general case [3]. 
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Theorem 5. There is a reduction from the discrete approach to the probabilistic 
approach for analyzing loss in interface adapter chains. 

Proof. Let there be a method availability vector pi and a method dependency 
matrix aji as expressed in the discrete approach. We construct corresponding 
method availability vector p[, method dependency matrix a^j, and conversion 
probability matrix t'j^ as expressed in the probabilistic approach as follows. If 
Pi is true, then set p'^ to one, else set p'^ to zero, a^j is just the same as aji. And 
set all t',, to one. Then we have: 

Oji ®Pi^ f\{o-]i Pi) = /\Pi 

j aji 

{a'j,,t'j,)(^p', = Y[t'^,p', = Y[p[ 

and it is easy to see that a component of Oji (X) pi is true if and only if the 
corresponding component of (a^j, t'j^)'Sip'^ is one, and that a component of Cji^pi 
is false if and only if the corresponding component of (a^j,ij-,j) (S p'i is zero. 

This shows how an interface adapter graph for the discrete approach can be 
converted to one for the probabilistic approach in a way that the adaptation 
operators in both approaches basically have the same behavior. Since all the 
mathematics for both approaches follow from the definition of the adaptation 
operators, we have just shown that the probabilistic approach can encompass 
the discrete approach. □ 

Next, we formally describe the equivalent problem for the discrete approach, 
which we will call CHAIN and is NP-complete Let us have an interface 
adapter graph {{Ii},{Ai}), where {li} is the set of interfaces and {Ai} is the 
set of interface adapters. Let a'^ be the method dependency matrix associated 
with adapter A^. Let S G {/;} be the source interface and T G {/j} be the 
target interface. Then the problem is whether there is an interface adapter 
chain [^p(i) , ^p(2) , • • ■ ,^p(m)] such that the source of ^p(i) is S, the target of 
Ap(^rn) is T, and ||t;'^|| = ||a^(™) (g) • • • (g) a^'^^ (g) a^^^^ (g I'gW is at least as large 
as some parameter N. 

Theorem 6. PROB-CHAIN is NP-complete. 

Proof. Given M methods in the target interface, use the method described 
above to convert an input for CHAIN to an input for PROB-CHAIN, where 
we also set all rm to j^. Then X^m ''^m '^ill be where n is the number 
of methods available from the interface adapter chain, so PROB-CHAIN with 
X set to ^ will solve CHAIN. Since CHAIN is NP-complete and it is easy to 
verify if an alternate chain results in smaller u^, PROB-CHAIN must 

also be NP-complete. □ 
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6 A greedy algorithm 



As shown in section [SJ the problem of finding an optimal interface adapter chain 
maximizing the probability of an argument being handled by a method in the 
target interface is an NP-complete problem. Short of developing a polynomial- 
time algorithm for an NP-complete problem, practical systems will have to use 
a heuristic algorithm or an exponential-time algorithm with reasonable perfor- 
mance in practice. 

Algorithm [T] is a greedy algorithm that finds an optimal interface adapter 
chain between a given source interface and a target interface. Given an interface 
adapter graph G, it works by looking at every possible acyclic adapter chain with 
an arbitrary source that results in the target interface t in order of increasing 
loss, taking advantage of equation (jl4p . until we find a chain that starts with 
the desired source interface s. 

In this context, loss means the probability that a method in the target inter- 
face cannot handle an argument given a fully functional service with the source 
interface, which is computed in algorithm [21 so the algorithm is guaranteed to 
find the optimal interface adapter chain. In the worst case, however, the al- 
gorithm takes exponential time since there can be an exponential number of 
acyclic chains in an interface adapter graph. 



Algorithm 1 A probabilistic greedy algorithm for interface adapter chaining, 
procedure Prob-Greedy-Chain(G = (V,E), s, t, {rm}) 

C <— {[]} > chains to extend 

M = ^ > discarded chains 

^ ^ {[] ^ Idim(i')} ■> method dependency matrixes 

while G ^ do ' 

c <— element of G minimizing Prob-Loss(c, _D, {r™}) 
if c 7^ [] A source{c[\\) = s then 
return c 

else if no acyclic chain not in G U M extends c then 

G^G-'{c} 

M ^ M U {c} 
else 

if c = [] then 

B ^ {[e]\e e E, target{e) = t} 

else 

B ^ {e : c I e e i?, target{e) = source{c[l])} 
end if 

remove cyclic chains from B 
C ^CUB 

D ^ DU{e: D[c] (g) depend{e) \e:ceB} 
end if 
end while 
end procedure 
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Algorithm 2 Computing the probabilistic loss of an interface adapter chain, 
function Prob-Loss(c, D, {r™}) 
s <r- source{c[l]) 

V ^ D[c\ (g) i;, 

return 1 - f^,^ Vm 
end function 



Algorithm [T] can be easily extended to support behavior similar to service 
discovery by checking whether the current source is among a potential set of 
source interfaces instead of just checking against one, as is done with a similar 
algorithm based on the discrete approach [2] . 

7 Conclusions 

Interface adapters can allow code written to use one interface to use another in- 
terface, and chaining them together can substantially reduce the effort required 
to create interface adapters. Since interface adapters will often be unable to 
convert interfaces perfectly, loss can be incurred during interface adaptation, 
and we need a rigorous mathematical framework for analyzing such loss. In- 
stead of just analyzing whether or not a method in a target interface can be 
provided, we have developed a probabilistic framework where partial adaptation 
of methods can also be handled. 

We developed the probabilistic framework by first constructing a probabilis- 
tic model for interface adaptation. Based on this, we defined mathematical 
objects and operations which probabilistically express loss in adapted inter- 
faces and interface adapters, which were then used to prove that probabilistic 
optimal adapter chaining is NP-complete and to construct a greedy algorithm 
which can construct an optimal adapter chain with exponential time in the worst 
case. These provide a more fine-grained approach to analyzing loss in interface 
adapter chains compared to a discrete approach. 

Future avenues of research include alternate probabilistic approaches which 
require weaker and more realistic assumptions that can still be feasibly used 
in real interface adaptation systems. Another avenue of research is to find 
good ways to derive the necessary probabilities from the interface adapters, ei- 
ther through empirical means where interface adapters are invoked on many 
arguments to measure the probabilities or through analytical means which can 
approximate the probabilities based on program structure. Finally, there re- 
mains the design and implementation of an actual interface adaptation system 
which takes advantage of the probabilistic approach to analyzing loss in interface 
adapter chaining. 
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